home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20000114-20000217
/
000193_news@columbia.edu _Thu Feb 3 16:59:57 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
4KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA03695
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 3 Feb 2000 16:59:57 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA24784
for kermit.misc@watsun.cc.columbia.edu; Thu, 3 Feb 2000 16:37:50 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: TCP time limit in MSKermit?
Message-ID: <M1uDg6ySQg77@cc.usu.edu>
Date: 3 Feb 00 14:08:48 MDT
Organization: Utah State University
To: kermit.misc@columbia.edu
In article <87cist$5l6$1@sylvester.vcn.bc.ca>, David Stow <dastow@vcn.bc.ca> writes:
> Is there a preset limit to how long Kermit will keep a TCP
> connection open? I want to link two computers with Arcnet cards
> running DOS, LSL, SMCARCWS (MLID), and MSK 3.15. I gave node 1 the
> arbitrary IP address of 123.123.123.123 (the machines are connected
> only to each other) and node 2 the address 123.123.123.124, and set
> node 2's port to TCP/IP * . I typed CONNECT, then set node 1's port
> to TCP/IP 123.123.123.124 and instructed it to CONNECT as well.
> Node 1 showed me this rejection letter from Node 2.
There is no time limit for a connection to persist. No SET anything
has any effect on TCP timing material. Note that DHCP attempts should NOT
be used because there is no DHCP server. Give the usual TCP/IP information
about own IP, subnet mask, gateway, nameservers for normal connections.
In your case there is no nameserver and no gateway, so leave them empty.
The TCP RST is received from the other side, which did TCP_ABORT
and that happens only if things are so very very slow that the machine
has given up hope of communicating (required response was delayed far far
too long).
We can see very long times from the TCP Debug information. The
time= item is the number of Bios clock ticks (18.2/sec) since network
comms were started, rtt= is the round trip time in Bios clock ticks,
and rto= is the timeout in Bios clock ticks. Your values are big for a
two station hookup, suggesting that the ARCnet link is not working well.
Joe D.
--------------
> Resolving address of host 123.123.123.124 ...
>
> ARP request sent. Sender_IP=123.123.123.123, Target_IP=123.123.123.123
> Sender_MAC=01
> ARP request sent. Sender_IP=123.123.123.123, Target_IP=123.123.123.123
> Sender_MAC=01
> ARP request sent. Sender_IP=123.123.123.123, Target_IP=123.123.123.124
> Sender_MAC=01
> ARP reply received. Sender_IP=123.123.123.124, Target_IP=123.123.123.123
> Sender_MAC=02
> ARP request received. Sender_IP=123.123.123.124, Target_IP=123.123.123.123
> Sender_MAC=02 ARP R
> Welcome to the MS-DOS Kermit Telnet server at [123.123.123.124].
> You are talking to the terminal emulator,
> adjust local echoing accordingly.
> Opt send will ttype
> Opt send will naws
> Opt send do sga
> time=29 rtt=2 avg=0 std_dev=3 rto=13
> time=29 rtt=0 avg=0 std_dev=2 rto=11
> Opt recv will sga
> RST received. Connection refused by host
>
> Node 2 waited only a few seconds before aborting, even though I
> had SET TIMERs OFF on both computers. Its screen read:
>
> Operating as a Telnet server. Waiting...
> ARP request received. Sender_IP=123.123.123.123, Target_IP=123.123.123.124
> Sender_MAC=01 ARP Request is for our IP; replying.
> LISTEN
>
> ARP request sent. Sender_IP=123.123.123.124, Target_IP=123.123.123.123
> Sender_MAC=02
> ARP reply received. Sender_IP=123.123.123.123, Target_IP=123.123.123.124
> Sender_MAC=01time=25137 rtt=2 avg=0 std_dev=2 rto=8
> SYN_RECVD
>
> Connection starting from [123.123.123.123].
> time=25145 rtt=2 avg=0 std_dev=3 rto=13
> Opt recv will ttype
> Opt recv will naws
> Opt recv do sga
> Opt send will sga
> time=25165 rtt=3 avg=0 std_dev=5 rto=21
> TCP_ABORT
>
>
> Any advice about how to avoid this snub would be welcome.